Reverse Business Engineering - Modelle aus produktiven R/3-Systemen ableiten

Je mehr sich betriebswirtschaftliche Softwarebibliotheken, wie bspw. R/3 von SAP durchsetzen, desto mehr vernimmt man auch “Klagen” der Anwender: komplexe und teure Einführungsprozesse, fehlende Übersicht, mangelndes Wissen über die Arbeitsweise des Systems und Schwierigkeiten bei der Anpassung werden regelmäßig auf der Negativliste angeführt. Während für die erst genannten Probleme bereits einige methodische und toolgestützte Hilfestellungen angeboten werden, haben sich bisher weder die Theorie noch die Praxis eingehender mit der effizienten Nutzung und Adaption bereits implementierter Softwarebibliotheken beschäftigt. Da aber gerade eine kontinuierliche Anpassung an veränderte Umweltbedingungen zu den zentralen Erfolgsfaktoren einer effektiven Softwarenutzung zählt, erscheint es äußerst lohnend, den Anwender dabei durch ein methodisch durchgängiges und einfach handhabbares Werkzeug zu unterstützen. Bei der von den Autoren entwickelten Vorgehensweise des Reverse Business Engineering werden produktive R/3-Systeme toolgestützt analysiert, um retrograd ein Modell der aktiv genutzten Elemente zu ermitteln und darzustellen. Nach Durchführung einer Vielzahl derartiger Projekte, kann eine Erfahrungsdatenbank aufgebaut werden, die dem Softwarehersteller hilft, sein System kundengerechter zu gestalten. Darüber hinaus können die gewonnenen Informationen auch zur Generierung von “Best-PractiseLösungen” herangezogen werden. Die Methode des Reverse Business Engineering hilft also nicht nur dem einzelnen Unternehmen bei der Analyse und Dokumentation seines Softwaresystems, sondern kann auch dem Hersteller profunde Wettbewerbsvorteile verschaffen. Schließlich profitiert auch die Betriebswirtschaftslehre von den aggregierten Praxis-Erfahrungen. 1 Reverse Engineering für Softwarebibliotheken wie SAP R/3 Eine Softwarebibliothek definiert sich durch eine sehr große Funktionsbreite, variantenreich ausprägbare betriebswirtschaftliche Profile, durch eine betriebstypund branchenorientierte Systematik der Entwicklung, technische und methodisch mächtige Adaptionswerkzeuge und eine hohe Flexibilität und Revidierbarkeit im Rahmen der kontinuierlichen dynamischen Adaption (Hufgard 1994, S. 71). Bei der Nutzung eines solchen komplexen Systems kommt der permanenten Anpassung an veränderte Umweltbedingungen eine hohe Bedeutung zu. Wenn eine derartige dynamische Adaption nicht durchgeführt wird, wenn also keine fortwährende Diagnose und Reverse Business Engineering 427 Qualitätssicherung stattfindet, kommt es nur allzu häufig über erste auftretende Schwächen und Probleme zu Krisen! Selbst für den Fall, daß es nicht zu einer Krise kommt, erscheint doch die Notwendigkeit einer kontinuierlichen Anpassung sowohl theoretisch wie praktisch allgemein anerkannt zu sein. So besteht auch in der Literatur Einigkeit darüber, daß der größte Teil des Aufwandes bei einem Softwaresystem nach dessen Einführung entsteht (Curth 1989, S. 7; Klösch 1995, S. 4; Müller 1997, S. 1 und Stahlknecht 1995, S. 160). Hauptursächlich hierfür ist der ständige Wandel der internen und externen Umweltbedingungen. Äußere Einflüsse bedingen innere Anpassungen und selbstinitiierte Verbesserungsmaßnahmen beeinflussen die Unternehmensorganisation. Folglich “klaffen” System und Realität immer auseinander: “Evolution is a natural phenomenon for such systems; it is not that someone forgot a requirement – the requirements inevitably change. There will always be old software.” (Mueller 1997). Die Vorgehensphilosophie und Methodik zur Lösung dieser Anforderung auf Basis einer Softwarebibliothek wie SAP R/3 wurden erstmals von Thome und Hufgard als “Continuous System Engineering” formuliert (Thome 1996). Ein wichtiger Baustein im Rahmen dieser Projektierungsphilosophie ist eine Analyseund Diagnosekomponente der “realen, aktiven Geschäftsprozesse”. Eine so geartete toolgestützte, permanente Istanalyse ist nicht nur zeitnaher, sondern liefert auch qualitativ bessere Ergebnisse und ist die Grundlage für ein “Reverse Business Engineering”. 1.1 Klassisches Reverse Engineering Das Konzept des Reverse Engineering steht nicht nur in sprachlicher Hinsicht dem Modellansatz des im Titel dieses Aufsatzes genannten Reverse Business Engineering nahe, sondern vor allem auch inhaltlich. Während allerdings das Reverse Engineering die Analyse auf den technischen Aspekt, nämlich die Analyse von Programmcodes, beschränkt, liegt beim Reverse Business Engineering der Schwerpunkt auf der betriebswirtschaftlichen Sicht und der Anwendungssituation. Aufgrund der sehr ähnlichen Zielsetzung erscheint eine kurze Auseinandersetzung mit den Methoden und Verfahren des Reverse Engineering sinnvoll. Unter Reverse Engineering wird die Analyse eines bestehenden Systems, mit dem Zweck der Identifikation von Systemkomponenten und deren Beziehung untereinander, sowie der Erzeugung von Darstellungen des untersuchten Systems auf unterschiedlichen, höheren Abstraktionsniveaus verstanden (Klösch 1995, S. 8; Lehner 1991, S. 234 und Stahlknecht 1995, S. 162). Hierbei handelt es sich um einen reinen Untersuchungsvorgang, der nicht die Durchführung von funktionalen Änderungen beinhaltet (Gutzwiller 1991, S. 4 und Klösch 1995, S. 8). 428 A. Hufgard, H. Wenzel-Däfler Reverse Engineering-Maßnahmen werden notwendig, da zum einen die Anwendungssysteme oft eine schlechte Qualität vorweisen und unzureichend dokumentiert sind (Lehner 1991, S. 233), zum anderen die im Laufe der Zeit immer komplexer werdende Software auf der konzeptionellen Ebene leichter überschaubar und verständlicher ist, als auf der Implementierungsebene (Sneed 1992, S. 259). Auch moderne Software Engineering-Methoden machen das Reverse Engineering nicht überflüssig, da häufig Änderungen und Wartungsaktivitäten ohne Anwendung dieser Methoden stattfinden. Vielfach fehlt hier eine durchgängige Werkzeugunterstützung (Gutzwiller 1991, S. 23). Reverse Engineering ist oft nur ein Teil eines Gesamtkonzeptes (Reengineering-/ Wartungskonzept) (Gutzwiller 1991, S. 5 und Richter 1992, S. 128) und unterteilt sich selbst in die Bereiche Redokumentation und Redesign (Klösch 1995, S. 8-9; Lehner 1991, S. 235 und Müller 1997, S. 12). Im Rahmen der Redokumentation wird zunächst eine semantisch äquivalente Repräsentation des betrachteten Objektes erzeugt. Im nächsten Schritt wird dann, im Rahmen des Redesigns, ein Modell erstellt, das ein höheres Abstraktionsniveau besitzt. Letzterer Schritt erfordert zusätzliche Informationsquellen zum Programmcode, wie bestehende Dokumentationen, persönliche Erfahrungen des Wartungspersonals und allgemeines Wissen über das Problem und das Anwendungsgebiet (Stahlknecht 1995, S. 162). Erfahrungen zeigen, daß ein erfolgreiches Reverse Engineering nur mit Werkzeugunterstützung denkbar ist, das Nachempfinden und Verstehen des ursprünglichen Designs oder strukturelle inhaltliche Verbesserungen jedoch Aufgabe des Entwicklers sind und bleiben werden (Wagner 1992, S. 15). Hieraus leitet sich die Anforderung ab, daß eine interaktive Kontrolle der Teilwerkzeuge und eine Bewertung der erzielten Ergebnisse jederzeit möglich sein muß. Ferner müssen die im Reverse Engineering-Prozeß erlangten Informationen werkzeugunterstützt weiterverarbeitet werden können (Stahlknecht 1995, S. 171). 1.2 Dokumentation der Einführung, Anwendung und dynamischen Anpassung Die Dokumentation der Programme, Funktionen und Abläufe im Bereich von Softwarelösungen ist häufig ein Problem in der Praxis, da die Verantwortlichen die Aufgabe einer umfassenden Beschreibung ihrer Systeme vernachlässigen und es in der Folge zu teilweise erheblichen Verständnisproblemen bei den Anwendern/Entwicklern kommt (Arnold 1997, S. 64). Standardsoftware sind dagegen meist mit einer aussagekräftigen Dokumentation ausgestattet. Das Problem liegt hier also nicht in der Beschreibung der technischen Möglichkeiten der Software, sondern vielmehr mangelt es den Anwendern von Softwarebibliotheken an einer transparenten, einheitlichen Dokumentation der komplexen betriebswirtschaftlichen Konfiguration und vorgenommener Anpassungen, die es nicht nur einem Experten – ermöglicht, den Einführungsprozeß und die zugrundegelegten Anforderungen zu einem späteren Zeitpunkt nachzuvollziehen und eventuell geReverse Business Engineering 429 zielt zu revidieren. Die Undurchsichtigkeit der einmal getroffenen und im Laufe des Adaptionsprozesses im Rahmen des Continuous System Engineering immer wieder veränderten Einstellungen (Thome 1996, S. 78-81) führt auch dazu, daß die Diskrepanz zwischen den organisatorischen Anforderungen und existierenden Systemeinstellungen nicht erkannt wird und sich immer mehr vergrößert. Die Folge ist ein ineffizient und ineffektiv genutztes Standardanwendungssoftwarepaket. Ein System, das technisch betrachtet problemlos läuft, kann in Einzelbereichen, aufgrund der engen Verzahnung der einzelnen Prozesse, kontraproduktiv arbeiten (Computerwoche 1998, S. 19). Das Wissen über den Ist-Zustand des Systems und seiner Einstellungen ist ferner Voraussetzung für die weitere Adaption der Software an veränderte Anforderungen. Ein weiterer, oftmals übersehener Aspekt einer nicht vorhandenen “aktiven” Dokumentation ist die Tatsache, daß selbst der Standardsoftwarehersteller, wie bspw. die SAP AG, keine oder nur sehr unzureichende Möglichkeiten hat, systematisch quantitative und qualitative Informationen über • die Nutzung einzelner Standardprozesse, • die Nutzung einzelner Standardfunktionen und • realisierte Sonderlösungen bzw. Modifikationen zu erlangen. Üblicherweise sind in Supportdatenbanken nur Fehlerund Problemsituationen bekannt. Ein solches “Sammelbecken” für Prozesse und Funktionen, Auswertungen und Schnittstellen, die im Laufe der Zeit von den Unternehmen, die SAP R/3 nutzen, realisiert worden sind, wäre sowohl für die SAP AG als auch für die Anwender von außerordentlich hohem Nutzen (Saller 1996, Folie 15), da dies wichtige Informationen zur Verbesserung und Weiterentwicklung der Software (die ja letztendlich dem Endanwender zu gute kommt) liefert. 2 Reverse Business Engineering-Ansatz Der zunächst noch unbekannte Begriff “Reverse Business Engineering” (RBE) wird beim Leser Assoziationen mit dem bereits etablierten Konzept des Business Process Re-Engineering hervorrufen. Und in der Tat geht es hier auch um die Gestaltung von Unternehmen und Prozessen. Aber im Gegensatz zu dem Modethema der neunziger Jahre strebt das “Reverse Business Engineering” nicht die radikale Änderung von Abläufen oder ganzen Organisationseinheiten (Hammer 1994) an, sondern will durch eine systematische, strukturiert und kontinuierlich betriebene Rückkopplung mit vielen aktiv genutzten Informationssystemen Verbesserungspotentiale in den Betrieben erschließen. Untersuchungsgegenstand für die “rückwärtsgerichtete Gestaltung” sind alle Prozesse im Unternehmen sowohl die Kernprozesse, als auch die untergeordneten Funktionen dienen dabei als Basis für das “Reverse Business Engineering”. 430 A. Hufgard, H. Wenzel-Däfler Aufgabe ist es nicht, wie es beim klassischen Reverse Engineering der Fall ist, mit Hilfe von Quellcode-Untersuchungen ein Abbild der Funktionalitäten der Software zu schaffen – diese sind in der Regel bei einer Softwarebibliothek bekannt. Aufgabe ist es vielmehr, basierend auf dem Gesamtmodell herauszufinden, welche Prozesse und Funktionen tatsächlich aufgrund der Customizing-Einstellungen, Stammdaten und Transaktionen wie oft und wie genau genutzt werden. Voraussetzung für das Erreichen eines solch‘ anspruchsvollen empirischen Ziels ist eine einheitliche und stabile Untersuchungsbasis wie SAP R/3, eine Modellstruktur wie das R/3Referenzmodell und ein mächtiges RBE-Analysewerkzeug. 2.1 Forward versus Reverse Business Engineering Im R/3-System liefert der sogenannte “Business Engineer” eine Modellstruktur für die Konfiguration der Softwarebibliothek auf die individuellen Anforderungen des Kunden. Diese Struktur führt den Anwender über mehrere (abstrakte) Modellebenen (Komponenten, Szenarien, Prozesse, Funktionen etc.) immer näher an das R/3-Customizing mit seinen Tabellen und Parametern heran (siehe Abbildung 1) (Schröder 1998). Abbildung 1: Modellhierarchie des Business Engineer Reverse Business Engineering 431 Beim “Reverse Business Engineering” wird die gleiche Struktur benutzt, die Zielsetzung ist aber genau entgegengerichtet: Es sollen ein oder mehrere bereits konfigurierte bzw. produktive R/3-Systeme analysiert und ihre Einstellungen im Modell abgebildet werden. Somit stellt das “Reverse Business Engineering” eine Umkehrung des normalen “Forward Business Engineering” (siehe Abbildung 2) dar.